Integration Guide Universal Robots PolyScope X LS 1.5

This guide describes how to integrate Universal Robots controllers that run PolyScope X with Locator Studio (LS) 1.5. The Robot module is a URScript library (photoneo_locator_X.script, protocol version 1.5.0) that is embedded in a set of .urpx example programs. You do not install a URCap.

Note

For the general concept of the communication, see the Robot communication overview. The supported versions of all Robot modules are listed in the Robot module support matrix.

There is also a URCap variant of this Robot module. It adds a settings page and program nodes to PolyScope X, so you do not write script lines by hand. See Integration Guide Universal Robots PolyScope X LS 1.5 (URCap). Both variants use the same protocol. You can use both in one cell, but not in one program.

1. Prerequisites

The Locator Studio Robot module for PolyScope X is a URScript library, photoneo_locator_X.script, and a set of .urpx example programs. Every example program contains the library. To install the Robot module, you only import an example program. There is no URCap to install and no script file to copy.

Before you start, make sure that your system meets these requirements:

  • A Universal Robots e-Series robot with PolyScope X system software

  • PolyScope X version 10.12.1 or higher

  • A free Ethernet port on the robot controller for the connection to the Photoneo vision controller

  • The Real-Time Data Exchange (RTDE) interface is enabled on the robot controller (see section 2.2)

  • A USB flash drive to copy the .urpx example programs to the robot controller

  • A Photoneo vision controller with Locator Studio that supports communication protocol 1.5.0

  • A Locator Studio solution with at least one calibrated vision system and a configured localization

  • MotionCam-3D for the dynamic MultiView (Instant Meshing) example. All other examples work with any supported Photoneo 3D sensor.

Note

This guide does not cover PolyScope 5 and CB-Series controllers. For them, use the Photoneo Robot module for PolyScope 5. It uses a different program format (.urp) and keeps the script as a file on the robot controller.

Note

When the library opens the socket to the Action Request Server, it sends the 24-byte brand ID UR/L/1.5.0XXXXXXXXXXXXXX. The vision controller uses this string to select the matching protocol version. Because of this, the vision controller must run a Locator Studio version that supports protocol 1.5.0.

To check the system version on your robot, go to Main Menu → About:

PolyScope X main menu with the About item

The PolyScope X version is on the first line (Software):

PolyScope X About dialog with the software version

2. Robot Controller Setup

2.1 Network Configuration

First, set the IP address of the robot controller port that connects to the Photoneo vision controller. Go to Main Menu → Settings:

PolyScope X main menu with the Settings item

Scroll down to Connection → Network. Select Static as the network method. Enter the IP address and the subnet mask of the robot controller. This guide uses 192.168.1.2 and 255.255.255.0. The network settings are password protected. Press Unlock and enter the administrator password before you change them.

Click Apply Configuration and then Lock and Close to confirm the changes.

PolyScope X network settings with a static IP address

Note

The subnet mask 255.255.255.0 is the same as a 24-bit subnet mask. See this table for more combinations: https://dnsmadeeasy.com/support/subnet

Example of a matching network configuration on the vision controller side:

  • Vision controller IPv4 address: 192.168.1.1 / 24

  • Robot controller IPv4 address: 192.168.1.2 / 24 (as configured in the previous step)

Network page of the vision controller with the robot controller IP address

You can also ping the robot controller from the vision controller. Use the Test connection button on the Network page of the vision controller:

Test connection button

The result of the test (a ping command) is shown in a message: Robot available or Robot unavailable. If the robot is unavailable, check the cables and the network configuration.

Test Status message Robot available
Test Status message Robot unavailable

2.2 Enabling Real-Time Data Exchange (RTDE)

Locator Studio reads the current joint positions and the tool pose of the robot through the Real-Time Data Exchange (RTDE) interface (port 30004). It uses these values to show the robot in the visualization on the vision controller. You do not install a Robot State Server program on the robot.

Go to Main Menu → Settings → Security → Services and make sure that Real-Time Data Exchange (RTDE) is enabled.

PolyScope X Services page with Real-Time Data Exchange enabled

Note

The Services page is password protected. Press Unlock and enter the administrator password before you change an interface.

Note

The calibration request and the hand-eye scan request do not need RTDE. They send the robot pose in the request itself: pho_calib_add_point(tcp_pose) and the optional tcp_pose argument of pho_request_scan. The example programs send get_actual_tool_flange_pose().

2.3 Loading the Robot Module Files

The Robot module consists of the library photoneo_locator_X.script (the request API described in section 3.2 - do not edit it) and these example programs:

  • pho_main_basic_loc.urpx

  • pho_main_basic_hand_eye_loc.urpx

  • pho_main_basic_multi_vs_loc.urpx

  • pho_main_change_bbox_loc.urpx

  • pho_main_change_solution_loc.urpx

  • pho_main_get_status_loc.urpx

  • pho_get_running_solution_loc.urpx

  • pho_main_reuse_scan_loc.urpx

  • pho_multiview_static_loc.urpx

  • pho_main_loc_MV_dynamic.urpx

  • pho_calibration_auto_loc.urpx

  • pho_calib_loc_hand_eye.urpx

Note

Copy only the .urpx programs to the robot controller. Every example program already contains the library as a Script node in its Before Start sequence. PolyScope X keeps the script inside the program, not in a separate file on the robot controller. The separate photoneo_locator_X.script file is for reference and for the update procedure in section 5.

Copy the .urpx files to a USB flash drive. Connect the drive to the USB port of the teach pendant or of the robot controller. Then click Main Menu → System Manager:

PolyScope X main menu with the System Manager item

In the System Manager, you open, save and change all programs on the robot. Press + Program, then Import Program, and select the example programs on the USB flash drive:

System Manager with the Import Program item

After the import, the Locator Studio example programs are on the Programs page of the System Manager. You can open them from there:

System Manager Programs page with the imported Locator Studio example programs

Note

PolyScope X does not keep robot programs as files in a /programs directory (as PolyScope 5 does). It keeps them in an internal application store. Because of this, you cannot copy programs with scp or an FTP client. Import them from a USB flash drive in the System Manager, as described above.

SSH access to the robot controller is available for diagnostics. It is disabled by default. To enable it, go to Main Menu → Settings → Security → Secure shell. There you set the port, the authentication method (password, key or both) and the authorized keys.

2.4 Tool (TCP) Setup

Locator Studio sends object poses in the robot base coordinate system. During the calibration and during a hand-eye scan, it must know where the robot flange is. The tool pose that the robot reports depends on the active end effector. Locator Studio works best with an all-zero tool, because it compensates the tool offset on the vision side. Use a zero tool for the calibration too.

On the left side, go to Application → End Effectors:

PolyScope X Application page with the End Effectors item

Make sure that the Tool_flange end effector has zero position and zero orientation values:

Tool_flange end effector with zero position and orientation

Note

The example programs send get_actual_tool_flange_pose() with the calibration request and the hand-eye scan request. This pose does not depend on the active end effector. These requests are correct also when a non-zero tool is active.

Note

The picking motions are different. The example programs move the robot to the pose from Locator Studio with the TCP that is active at that moment. For picking, the active end effector must describe the real gripper. If you need both, activate your own end effector for your own movej / movel motions, and switch back to Tool_flange for the Photoneo requests.

3. Robot Module

Note

We strongly recommend that you read the Photoneo robotic API before this section.

3.1 Connection to the Photoneo Vision Controller

The program opens the connection to the Action Request Server on the vision controller at the start with pho_wait_for_server. You can send requests only after the connection is open. The function is defined in photoneo_locator_X.script. Do not edit it.

Request

Script definition

Input

Populates

Connect to the Action Request Server (vision controller)

pho_wait_for_server(server_ip, port=PHO_LOCATOR_PORT_DEFAULT, max_attempt=1)

server_ip - IP address of the vision controller

port - default 11003

max_attempt - number of connection attempts, default 1

PHO_ERR_CODE

The example programs call pho_wait_for_server(IP_ADDRESS) in Before Start, with IP_ADDRESS set to "192.168.1.1". Change this value to the IP address of your vision controller. The function closes the old socket before it opens a new one, so every program start opens a new connection.

Note

If the socket cannot be opened, the library sets PHO_ERR_CODE to 3 (communication failure) and stops the program. When the connection is open, the Deployment page of Locator Studio shows the Action Request Client as CONNECTED (green).

3.2 Request List

This section describes the API functions of the Robot module. Use them for high-level control of the Locator Studio application. For details about each request, see Action requests.

Note

These functions are defined in the API section of photoneo_locator_X.script. Do not edit them.

Note

The ID column shows the request ID that is sent over the Photoneo communication protocol. Where two script definitions are shown, the second one is a short alias that calls the first one.

Request

ID

Script definition

Input

Populates

Scan and localize

19

pho_request_scan(vision_sys_id, tcp_pose=PHO_EXTRINSIC_VS)

Vision system ID

Flange pose (optional, hand-eye): get_actual_tool_flange_pose()

Non-blocking. Collect the response with pho_wait_for_scan_completion().

Wait for scan

-

pho_wait_for_scan_completion(timeout=-1)

Timeout [s] (optional, -1 = wait without limit)

PHO_ERR_CODE

Trigger scan (MultiView)

30

pho_trigger_scan(vision_sys_id, tcp_pose=PHO_EXTRINSIC_VS)

Vision system ID

Flange pose (optional)

Non-blocking. Collect the response with pho_wait_for_scan_completion().

Reuse scan (localize on the last scan)

31

pho_reuse_scan(vision_sys_id, tcp_pose=PHO_EXTRINSIC_VS)

Vision system ID

Flange pose (optional)

Non-blocking. Collect the response with pho_wait_for_scan_completion().

Get objects

20

pho_request_get_objects(vision_sys_id, num_of_req_objects)

Vision system ID

Number of requested objects (0 = all)

PHO_ERR_CODE, pho_object_poses, pho_number_of_objects, pho_dimensions_x, pho_dimensions_y, pho_dimensions_rot, pho_nn_label, pho_max_height, pho_angle

Get all objects

20

pho_request_get_all_objects(vision_sys_id)

Vision system ID

As Get objects, with the number of objects set to 0

Get single object

20

pho_request_get_single_object(vision_sys_id)

Vision system ID

As Get objects. Also copies the first pose to pho_object_pose.

Get vision system status

22

pho_request_get_vs_status(vision_sys_id)

Vision system ID

PHO_ERR_CODE, pho_num_localized, pho_num_ready, pho_process_state

Change bounding box

33

pho_request_change_bbox(vision_sys_id, bbox_id)

pho_change_bbox(...)

Vision system ID

Bounding box ID

PHO_ERR_CODE

Calibration start

25

pho_request_calib_start(solution_id, vision_sys_id)

pho_calib_start(...)

Solution ID

Vision system ID

PHO_ERR_CODE

Calibration add point

5

pho_calib_add_point(tcp_pose)

Flange pose: get_actual_tool_flange_pose()

PHO_ERR_CODE

Calibration save

27

pho_request_calib_save()

pho_calib_save()

None

PHO_ERR_CODE, pho_calib_acc, pho_camera_pose

Calibration stop

26

pho_request_calib_stop()

pho_calib_stop()

None

PHO_ERR_CODE

Change solution

9

pho_request_change_solution(solution_id)

Solution ID

PHO_ERR_CODE

Start solution

10

pho_request_start_solution(solution_id)

Solution ID

PHO_ERR_CODE

Stop solution

11

pho_request_stop_solution()

None

PHO_ERR_CODE

Get running solution

12

pho_request_running_solution()

None

PHO_ERR_CODE, pho_running_solution

Communication check

100

pho_request_comm_check()

pho_comm_check()

None

PHO_ERR_CODE

Three requests are non-blocking: pho_request_scan, pho_trigger_scan and pho_reuse_scan. Collect the response with pho_wait_for_scan_completion(). With a hand-eye sensor, keep the robot still until the scan response arrives. With an extrinsic sensor, the robot can move in the meantime if it stays out of the scanned scene. The only exception is dynamic MultiView, where the sensor scans while the robot moves. If a response is still pending, every other request collects it before it sends its own request, so no response is lost. All other requests wait until the vision controller answers.

Note

If you call pho_wait_for_scan_completion() when no scan request is pending, it shows a Program flow error message and halts the program.

3.3 Object Picking and the Approach Pose

A complete Locator Studio cycle has four steps:

  1. pho_wait_for_server - once, at the start of the program.

  2. pho_request_scan - start the scan and the localization.

  3. pho_wait_for_scan_completion - wait until the vision controller confirms the scan.

  4. pho_request_get_objects - read the poses of the localized objects from pho_object_poses.

Locator Studio sends the pose of the object itself. Unlike Bin Picking Studio, it does not plan a trajectory. The robot program controls all motion: it calculates an approach pose above the object, moves there, moves to the object, closes the gripper and moves away. The library has two helper functions for this:

Function

Input

Returns

pho_get_approach(target, offset_z)

target - the object pose

offset_z - offset in meters

The target pose with offset_z added to its Z coordinate in the base coordinate system

pho_get_offset(target, offset_value, method, axis)

target - the object pose

offset_value - offset in meters

method - "Base Offset", "Base Plane", "Tool Offset" or "Tool Plane"

axis - "X", "Y" or "Z"

The offset pose. The function first checks that this pose and the poses near it are reachable.

Note

Use pho_get_approach() for a vertical offset. Use pho_get_offset() when the offset must follow the orientation of the object. The Tool methods offset along the axis of the object, so the robot approaches a tilted object along its own direction. pho_get_offset() also checks the object pose, the offset pose and two safety poses (2 cm past the object and 2 cm past the offset pose) with is_within_safety_limits(). If a pose is not reachable, it shows a blocking message before the robot moves. pho_get_approach() does not check anything. Section 4.1 describes the offset methods.

3.4 Result Variables

The requests do not return values. They write their results to global variables of the library. The robot program can read these variables at any time after the request. A variable keeps its value until the next request changes it. For the meaning and the units of the values sent by the vision controller, see Info data.

Variable

Set by

Meaning

PHO_ERR_CODE

every request

Response code of the last request (see section 3.5)

PHO_OCCURRED_ERR

every request

True when the last request returned a response code other than 0

pho_object_poses

pho_request_get_objects

List of up to 100 object poses in the robot base coordinate system (p[x,y,z,rx,ry,rz], [m], [rad])

pho_number_of_objects

pho_request_get_objects

Number of object poses that were received

pho_object_pose

pho_request_get_single_object

Copy of the first received pose

pho_dimensions_x, pho_dimensions_y

pho_request_get_objects

Width and depth of each object [mm] - only for localization without a CAD model

pho_dimensions_rot

pho_request_get_objects

Rotation of each object around Z [deg] - only for localization without a CAD model

pho_nn_label

pho_request_get_objects

Class label from an AI solution

pho_max_height, pho_angle

pho_request_get_objects

Maximum Z height [mm] and tilt angle [deg], used by layer solutions

pho_num_localized

pho_request_get_vs_status

Number of localized objects

pho_num_ready

pho_request_get_vs_status

Number of objects that are ready to be picked

pho_process_state

pho_request_get_vs_status

0 = processing has finished, 1 = localization is still running

pho_calib_acc

pho_calib_save

Calibration accuracy sent by the vision controller [µm]

pho_camera_pose

pho_calib_save

Camera pose that results from the calibration

pho_running_solution

pho_request_running_solution

ID of the solution that is deployed on the vision controller

Note

The library converts pho_dimensions_rot and pho_angle from milliradians (as sent) to degrees. All other values are stored as they are sent.

3.5 Response Codes

Every request writes its result to PHO_ERR_CODE. If the code is not 0, the request also sets PHO_OCCURRED_ERR. The library defines a named constant for each code. Your program can compare the code with the name instead of the number, for example if PHO_ERR_CODE == PHO_NO_OBJ_RUN:. Codes 3 and 4 stop the program. All other codes are only reported, and the program continues, so that it can react. For the full description of each code, see Error codes.

Code

Constant

Meaning

0

PHO_NO_ERROR

The request was successful

1

PHO_SERVICE_ERR

Service error - the process that handles the request is not available (for example, no LS solution is deployed)

2

PHO_UNKNOWN_REQ

The vision controller does not know the request

3

PHO_COM_FAILURE

Communication failure - the program stops

4

PHO_BAD_DATA

Incorrect data received - the program stops

5

PHO_TIMEOUT

The response did not arrive within the timeout

450 - 459

PHO_INVALID_SOL … PHO_SOL_FORBIDDEN

Solution management: invalid solution ID, another solution is running, start or stop error, solution incomplete, invalid brand ID, solution already running, operation forbidden

460 - 469

PHO_INVALID_VS … PHO_CALIB_FORBIDDEN

Calibration: invalid vision system, calibration already running or not running, stop or start error, calibration disabled, not enough calibration points, calibration accuracy above the allowed threshold, scanner not available, calibration forbidden

500

PHO_VS_NOT_FOUND

The requested vision system does not exist

501

PHO_EMPTY_SCENE

Empty scene

502

PHO_NO_OBJ_RUN

No object found yet, the localization is still running

503

PHO_NO_OBJ_STOP

No object found, the localization has finished

504

PHO_REJECT_RUN

All objects found so far were rejected, the localization is still running

505

PHO_REJECT_STOP

All objects were rejected, the localization has finished

3.6 Example Programs

The Robot module includes several .urpx example programs. They show how to use the requests from section 3.2 for different use cases. All main examples have the same structure: the Before Start sequence connects to the vision controller and sets the offset parameters. The Photoneo pick and place loop folder contains the Picking and Placing folders.

Example program

Description

pho_main_basic_loc

The basic template - start here. It shows the complete workflow: connect to the vision controller, send a scan request, wait for the scan, read the object poses with pho_request_get_objects() and pick the objects one by one.

NUM_OF_REQ_TAR sets how many object poses the program requests after each scan (2 in the delivered program). The Picking folder then loops over pho_object_poses[increment].

Every request writes its result to PHO_ERR_CODE. The program checks this value and does not stop on an error.

pho_main_basic_hand_eye_loc

The same as pho_main_basic_loc, but for a scanner that is mounted on the robot flange. The program sends the scan request from a taught scanning pose as pho_request_scan(VISION_SYS_ID, tcp_pose=get_actual_tool_flange_pose()). This tells the vision controller where the sensor was during the scan. It requests 3 objects.

pho_main_basic_multi_vs_loc

The same as pho_main_basic_loc, but it switches between two vision systems. The VISION_SYS_ID variable selects the vision system for the scan and for the Get objects request. The program changes it between 1 and 2 after each pick cycle.

pho_main_change_bbox_loc

The same as pho_main_basic_loc, but it shows pho_request_change_bbox(). Use this when the scene has not changed, but the localization must run again in a different region of interest. Prepare a vision system with at least two bounding boxes. The program switches between them with the BBOX_ID variable.

pho_main_change_solution_loc

The same as pho_main_basic_loc, but with all solution requests. In Before Start, it reads the deployed solution with pho_request_running_solution(). If this is not SOLUTION_ID, it stops it with pho_request_stop_solution() and starts SOLUTION_ID with pho_request_start_solution(). After each pick cycle, it switches between solutions 1 and 2 with pho_request_change_solution(SOLUTION_ID).

pho_main_get_status_loc

The same as pho_main_basic_loc, but it calls pho_request_get_vs_status() four times after the scan. You can call this request repeatedly at short intervals during the localization. It returns pho_num_localized, pho_num_ready and pho_process_state. Use these values to find the best moment to read the object poses. The program then requests pho_num_ready objects.

pho_get_running_solution_loc

The same as pho_main_basic_loc, with two status requests in the loop: pho_request_get_vs_status() and pho_request_running_solution(). The second one returns the ID of the solution that runs on the vision controller. NUM_OF_REQ_TAR is 0, so the program requests all localized objects.

pho_main_reuse_scan_loc

Shows the reuse scan request. Use it when the scene has not changed since the last scan, but the localization must run again with a different configuration (another object, another bounding box or other settings). When VISION_SYS_ID is 1, the program sends a normal scan request and waits for it. When it is 2, it sends pho_reuse_scan(), which localizes again on the existing data. The program switches VISION_SYS_ID after each pick cycle.

pho_multiview_static_loc

Static MultiView (meshing) example. The program combines several scans before the localization starts. This helps with complex scenes or large objects. The robot stops at each scanning position (Start, Middle, End), calls pho_trigger_scan() with the current flange pose and waits for the capture. Then a normal scan request starts the localization. This request does not trigger the projector, it only localizes on the combined data.

Scan limit: for best performance, use fewer than 10 scans in total.

pho_main_loc_MV_dynamic

Dynamic MultiView example: Photoneo Instant Meshing with MotionCam-3D. A parallel thread calls pho_trigger_scan() every CAPTURE_GAP seconds (0.5 s in the delivered program) while MESH_DYNAMIC is True and the robot moves along the scanning trajectory. Then a single normal scan request starts the localization.

Requirements: MotionCam-3D is required. Standard PhoXi 3D Scanners do not support dynamic scanning.

Trajectory: keep the scanning trajectory smooth, avoid sudden rotations and keep the scanned area in the field of view, so that the tracking is not lost.

Scan limit: use no more than 60 scans in total.

pho_calibration_auto_loc

Automatic calibration of a statically mounted scanner. In Before Start, the program stops the running solution and calls pho_calib_start(SOLUTION_ID, VISION_SYS_ID). Then it moves to nine taught calibration poses (one in each of the folders 1. Calibration Pose to 9. Calibration Pose) and calls pho_calib_add_point(get_actual_tool_flange_pose()) at each pose. At the end, it calls pho_calib_save() and pho_calib_stop().

Requirements:

  • The initial calibration of the vision system is done and confirmed manually in Locator Studio.

  • Automatic calibration is enabled for the vision system. Otherwise, pho_calib_start returns error 465.

  • The nine calibration poses are the same robot poses as in the initial calibration. The automatic calibration reuses the calibration poses of the last calibration done by the operator.

Calibration accuracy: as a general rule, the calibration error must be less than 3 mm. A larger error usually shows a systematic problem in the calibration setup.

Important: the scanner is statically mounted, so the calibration object is the calibration ball mounted on the flange or gripper. The ball moves with the robot through the calibration poses. It must stay in the same place on the flange or gripper as in the initial calibration - do not remount or move it in between.

pho_calib_loc_hand_eye

Calibration of a hand-eye scanner (mounted on the robot flange). The nine calibration poses are taught with the scanner on the flange. The program contains only the nine pho_calib_add_point(get_actual_tool_flange_pose()) calls. It does not start, save or stop the calibration. Do these steps in Locator Studio. At the end, the program reminds you to save the result on the vision controller.

4. Runtime

When the solution is completely configured on the vision controller, do the last steps on the robot side and run the Locator Studio program.

4.1 Approach and Deapproach Offset Parameters

Locator Studio sends the pose of the object. The robot must not move straight to it. The example programs approach the object from a distance and move away in the same way. The folders Approach offset parameters and Deaproach offset parameters in the Before Start sequence contain the values for this:

Variable

Delivered value

Meaning

APPR_OFFSET

0.1

Approach distance in meters

APPR_AXIS

"Z"

Axis for the approach offset

APPR_METHOD

"Tool Offset"

Method used to calculate the approach offset

DEAPPR_OFFSET

0.2

Deapproach distance in meters

DEAPPR_AXIS

"Z"

Axis for the deapproach offset

DEAPPR_METHOD

"Base Offset"

Method used to calculate the deapproach offset

The library accepts these methods:

  • Base Offset - adds the offset along the selected axis in the base coordinate system

  • Base Plane - sets the coordinate along the selected axis to the offset value (base coordinate system)

  • Tool Offset - moves the pose back by the offset along the selected axis of the object (tool) coordinate system

  • Tool Plane - calculates where the Z axis of the object crosses the plane at the offset value along the selected base axis

Note

pho_get_offset() uses these four methods and checks that the calculated poses are reachable before the robot moves. The simpler pho_get_approach(target, offset_z) ignores the method and axis variables. It always adds the offset to the Z coordinate in the base coordinate system and does not check reachability. See section 3.3.

4.2 Teach Positions

Open pho_main_basic_loc or another template. Before you run the program, touch up these five poses to fit your cell: Scanning, Pick_start, Before_place, Place and Deappr_place. The robot scans from the Scanning pose. It returns to Pick_start before it approaches the next object.

The MultiView examples use the scanning poses Start, Middle and End instead of Scanning. The calibration examples use Calib_Home and the nine poses Calib_Pose_1 to Calib_Pose_9.

Note

Do not rename these waypoints. The program uses their names. If you rename a waypoint, the move nodes have no target.

4.3 Runtime Prerequisites

Before you run the Locator Studio program from the robot side for the first time, make sure that:

  • the Locator Studio solution is correctly configured on the vision controller

  • the network setup on the robot side is complete

  • RTDE is enabled (section 2.2)

  • IP_ADDRESS in Before Start is the IP address of your vision controller (section 3.1)

  • all vision systems in the solution are calibrated

  • all poses in the main program are touched up correctly

  • the approach and deapproach offsets are set for your gripper (section 4.1)

  • the gripper commands are ready and work

4.4 Running the pho_main_basic_loc Program

Deploy your solution. Until the robot program connects, the Deployment page shows the Action Request Client as DISCONNECTED:

Locator Studio Deployment page with the Action Request Client disconnected

Note

We strongly recommend that you set the Speed slider on the teach pendant to 20% before you run the program for the first time.

PolyScope X speed slider set to 20 percent

Start the program. When the connection is open, the Action Request Client status changes to CONNECTED. The sensor takes the first scan and the localization starts.

Locator Studio Deployment page with the Action Request Client connected

If there is a pickable object in the scene and the robot controller receives its pose, the robot starts to move to the first object.

If everything looks correct, continue to move the robot to the first object and check the path. If the robot stops too far from the object or pushes the object too deep, adjust the object origin or the tool setup.

If the robot movement is correct, set up your own placing routine and slowly increase the speed to 100%.

The Photoneo Universal Robots interface now works. To improve your application, use the example programs in section 3.6 and the request list in section 3.2.

5. Robot Module Update

To update the Robot module to a version that matches your Locator Studio version, do these steps:

  1. Import the new example program. Import the .urpx program of the new Robot module version as described in section 2.3. It already contains the matching photoneo_locator_X.script, so you do not replace a script file on the robot controller.

  2. Or replace the library in your own program. Open your program and select the Script node with the Photoneo library in the Before Start sequence. Press Edit Script and replace its content with the content of the new photoneo_locator_X.script.

  3. Check the API changes. Read the API changes of the new Robot module version and update the request calls in your program if necessary. The changes from LS 1.4 are listed in section 7.

The library version is written in the header of the library (Zebra Technologies Locator communication library v 1.5.0). The brand ID that the Robot module sends to the vision controller is described in section 1: UR/L/1.5.0 for the 1.5 library.

6. Version and Brand ID

Item

Value

Robot module version

1.5.0 (photoneo_locator_X.script)

Locator Studio

1.5

Brand ID (sent by pho_wait_for_server)

UR/L/1.5.0XXXXXXXXXXXXXX

Action Request Server port

11003

Robot state (RTDE)

Port 30004 on the robot controller - read by the vision controller, no robot program needed

7. Migration

For the changes in the communication interface, see Migration from LS 1.4.x to LS 1.5.x.

Two scan functions have new names in the 1.5 library. The delivered example programs already use the new names. If your own program was written for the 1.4 library, rename these calls when you replace the library (section 5), and add the wait shown in the table. Otherwise the program stops with an error about an unknown name.

Up to 1.4

From 1.5 (photoneo_locator_X.script)

Note

pho_request_trigger_scan(vision_sys_id, tcp_pose)

pho_trigger_scan(vision_sys_id, tcp_pose)

New name, same behavior

pho_run_loca_on_last_scan(vision_sys_id)

pho_reuse_scan(vision_sys_id, tcp_pose)

New name. It also accepts an optional pose, like the other scan requests. Unlike pho_run_loca_on_last_scan, it does not wait for the response. Call pho_wait_for_scan_completion() after it, before you check PHO_ERR_CODE.